#ifndef GLOBALSTATIC_H_
#define GLOBALSTATIC_H_

const char PROMDATE_VERSION[] = PACKAGE_VERSION;

enum moduleHandlerTypes {
	STRINGSTATUS = 1,
	INTSTATUS = 2,
	DOUBLESTATUS = 4,
	BOOLSTATUS = 8,
	CONTROLELEMENT = 16,
	STRINGCONTROL = 32,
	INTCONTROL = 64,
	DOUBLECONTROL = 128,
	CHECKBOXCONTROL = 256,
	RADIOCONTROL = 512,
	STATUSELEMENT = STRINGSTATUS | INTSTATUS | DOUBLESTATUS | BOOLSTATUS,
	CONTROL = STRINGCONTROL | INTCONTROL | DOUBLECONTROL | CHECKBOXCONTROL | RADIOCONTROL,
	REMOVED = 1024,
};

#include "ConnectionManager.h"
extern ConnectionManager* gConnMan;

#include "URLManager.h"
extern URLManager* gURLMan;

/**
 * \mainpage Intent
 *
 * ProMDATE was designed to allow remote access to test equipment at Arizona State University by David Blyth and Matthew Gibson.
 * It is able to monitor and control an arbitrary number of tasks over the Internet.  Each task represents, in a conventional sense,
 * a separate program or experiment.  In the context of ProMDATE, however, these are referred to as \ref modules "modules".
 *
 * The primary goals of ProMDATE, beyond accomplishing these tasks, are to do so passively, simultaneously, and safely.  ProMDATE
 * requires an extremely small CPU overhead because it is designed to be passive -- no action is taken by ProMDATE unless it is
 * specifically requested by the web-user or by a module.  ProMDATE also executes modules and web connections simultaneously through
 * the use of POSIX standard threads.  This implies the third goal, safety.  ProMDATE has provisions to allow for safe passage of information
 * between a modules' threads as well as between the web server and the modules, all completely transparent to the web-user and module.
 *
 * Information which will help to use and contribute to ProMDATE can be found in these pages:
 * - \subpage install
 * - \subpage directory
 * - \subpage modules
 * - \subpage modhand
 * - \subpage elements
 */

/**
 * \page install Installation
 *
 * After downloading and extracting the tarball, cd to the newly extracted ProMDATE folder. This directory contains the source code for
 * ProMDATE as well as an example module which will also need to be compiled.
 *
 * execute <tt>make all</tt> this command will build the necessary libraries and binaries for ProMDATE to run.  Once it completes, run
 * <tt>make install</tt> (you may need root privileges) to install libraries to /lib or /lib64 (determined by <tt>uname -m</tt>) and binaries
 * to /usr/bin/.
 *
 * ProMDATE has a mandatory first argument of a base directory.  This is to locate the various files and directories ProMDATE requires
 * to operate.  Thus, run <tt>promdate ./</tt> from the ProMDATE directory.  The default port ProMDATE binds to is 1024.  As of now, there is no
 * provision to change this on the fly, but it can easily be changed in the source code.
 *
 * You should now have a working ProMDATE running on your machine, verify this by navigating to localhost:1024 in your web browser.  You can navigate
 * through the documentation, but no modules are available to be loaded.  These must first be compiled.
 *
 * Navigate to the module directory within the base ProMDATE directory.  Running <tt>make all</tt> in this directory will compile the test module
 * TestMod with the required file extension \a .daqmod.  After refreshing your browser, you should now see the option to load TestMod, which means
 * you've successfully installed everything that comes with ProMDATE.
 */

/**
 * \page directory Directory Structure
 *
 * ProMDATE comes with a simple directory structure to organize different sections of functionality
 *
 * \section PDir ProMDATE
 * the defualt name of the main ProMDATE directory.  All required files are contained within after un-taring.
 *
 * \section binDir bin
 * Contains the main ProMDATE executables after compliation.  You can edit the makefile if a different location is desired.
 *
 * \section buildDir build
 * Contains .o objects created by the compiler and eventually linked by the linker into the promdate executable.
 *
 * \section docDir documentation
 * Contains html documentation which is required by ProMDATE as it is hosted on it's website.
 *
 * \section inclDir include
 * Contains source header files.
 *
 * \section libDir lib
 * By default the \ref modhand "ModuleHandler" library is built to this location.  It must then be moved to the appropriate lib directory (see \ref install "Installation").
 *
 * \section modDir modules
 * Contains a directory structure for modules, but in the context of ProMDATE, only the libraries placed in the modules directory with the file extension .daqmod are
 * important.  These are manipulated by the server according to user input from the web.
 *
 * \section srcDir src
 * Contains source code for ProMDATE.
 */

/**
 * \page modules Modules
 * The idea behind ProMDATE is to lay a platform for executing and controlling independently written modules remotely.  Modules are compiled as dynamic libraries
 * which can be accessed by the ProMDATE server.  However, this requires ProMDATE to know a little bit about the module it is trying to run, so there are two mandatory
 * methods to all Modules -- start(ModuleHandler* handler) and stop(ModuleHandler* handler).  These are the entry and exit points for all modules.  The start() method can be
 * thought of as a main(), while stop() does not have as precise an analogy, it is executed to tell the module it has been unloaded and should safely shut down.  This can occur
 * for a number of reasons ranging from someone clicking the unload button to a crash in ProMDATE.  In any case, ProMDATE will wait on the module until the stop() method returns.
 *
 * The other mandated behavior of modules is to recognize that whichever thread start() is called from, by default, is the only one which can call waitForButtonPush() without a
 * dead lock.  This is to ensure there can be no missed button clicks while a module is starting up.  ProMDATE, of course, does not require you to use your start() thread to listen
 * for button clicks (although you can).  The methods getLock() and giveLock() are provided to safely allow the transfer of this lock to another thread without the risk of missed
 * button signals.  The getLock() method is to be called by the new thread, while giveLock() is called by the start() thread.  Misuse of these methods can result in a dead lock.
 *
 * There are two actions a module can take that are guarenteed to cause a crash in ProMDATE. The first is by deleting their own ModuleHandler.  The second is by deleting their own
 * library.  The second can be avoided by avoiding the ModuleHandler::getModLib() method.  However, it's entrusted to module creators to responsibly handle the pointer to their own
 * ModuleHandler.  Rest assured, the server will delete ModuleHandler, you don't have to.
 *
 * Beyond these few caveats, there are no restrictions placed on you for developing your modules.  ProMDATE has been designed to allow the module creators to do whatever they wish
 * while providing a simple and intuitive web interface.
 */

/**
 * \page modhand %ModuleHandler
 * ModuleHandler is the class which all module developers must become familiar with.  It is used to communicate between the module and the server and thus the module and the web-user.
 * This is done through \ref elements "Elements".  The best way to learn to use ModuleHandler is to read it's documentation page and look at the provided module example, TestMod.
 *
 * A goal of ProMDATE's was to ensure the safety of module's accessing data as well as ease of use by modules, so there is not need to take thread-safety precautions when using
 * ModuleHandler.  However, there are a few things which will cause catastrophic failures (i.e. crashes) to ProMDATE.  Modules should never delete their ModuleHandler, and likewise,
 * never delete the pointer to their own library (gotten by calling ModuleHandler::getModLib()).
 */

/**
 * \page elements Elements
 */

#endif /* GLOBALSTATIC_H_ */
